Automated test equipment (ATE) comprises apparatus operable for performing high speed testing on semiconductor devices such as integrated circuit (IC) chips. The testing is conducted to verify that memory, logic and other IC devices function properly during and after their development, fabrication, manufacturing and production processes. During their development, designers, engineers and other artisans skilled in semiconductor technologies use electronic design automation (EDA) and/or simulation tools to generate test patterns, which run on the ATE.
The test patterns comprise specific sequences of data signals, which the ATE input to typically multiple IC devices under test (DUTs). Each of the specific data signal sequences is generated to stimulate or evoke a particular responsive output from the DUTs, which the ATE monitor and evaluate to characterize one or more aspects or features of each DUT. The testing may comprise multiple specially generated test patterns and span multiple iterations, repetitions and/or generations, each with variations of test focus and test patterns based on a design of the DUTs.
For example, developing memory and other IC devices may comprise multiple EDA stages. Initial high level algorithmic and behavioral syntheses may be followed by synthetic translation of abstract logical language into discrete netlists of logic gates and/or memory cells, schematic capture and layout. Device level or “transistor,” Boolean level and high level architectural simulation stages, clocking, hardware and in-circuit emulation, computer assisted design (CAD) simulation are then performed, which is followed by analysis, functional verification and operational evaluation.
In developing memory and other IC devices, designers use EDA or simulation tools to generate specific test patterns desired for examining a particular feature, characteristic or behavior of a particular device and store files associated with the generated test patterns in file servers by the design group. At some point, the designers' test patterns stored in the file servers are transferred to engineers within a test engineering group for validation, in which the test patterns proposed and stored by the designers are converted into formats, which may subsequently be read by the ATE.
For example, FIG. 1 depicts a typical pathway 10 for transferring test patterns by a conventional approach. Upon synthesizing a high level behavioral and algorithmic design of memory and other IC devices, designers translate abstract logical language associated with the high level design into a netlist of discrete gates and cells and related schematics, layouts and/or other representations and develop the test patterns for verifying the translated designs. During these stages of development, a variety of EDA related files developed by the designers are typically stored in and accessed from a design database 11 local to the design group.
The files may comprise various formats used in the abstraction and translation of the design. As design development and refinement continues, the volume of data stored in these files grows and may evolve into branches, sequences and versions. To implement the verification of the designs, the EDA related files are typically transferred to an engineering database 12. Engineers may thus confront a large number of files in the various formats exported from the database 11. The file formats may include data written in graphics languages (e.g., GL, GDSII, etc.), source code (e.g., W, etc.), hardware descriptive languages (e.g., Verilog and associated languages such as VCD, VHDL or “VHSIC-HDL,” HDL, etc.) and test interface languages such as STIL.
The engineers and associated test technologists access the files stored in the engineering database 12 and may interpret or use these data to compile or generate any number of automated testing or “ATE” files, which can be read by the ATE environment and are stored in a test database 13. An ATE apparatus 15 may be operable for accessing the stored ATE files from the database 13 and programmably controlling or executing a single or series, sequence or group of associated test patterns over multiple like DUTs 14. Upon the ATE 15 executing the test over the DUTs 14, data 16 relating to the test results is returned to the design database 11, where it may be accessed and evaluated to complete one, single iteration.
In the event that everything generated, stored, transferred and converted as discussed above now runs smoothly and according to plans, proposals and expectations, the converted test patterns may then be downloaded to testing hardware components of the ATE, read and executed therewith. Test result data may then be sent for interpretation and evaluation back to the designers, which completes one single iteration for debugging a test pattern and/or the DUTs based thereon. At this point, the conventional process loop for validating an IC design returns to the origin point.
At the origin point with the design group, the process loop for developing the IC device then begins a subsequent iteration. The reiterative character of this conventional approach, requiring both online and offline processes, adds significant latency (days to weeks) and cost to the development process for IC device design and renders the conventional process inefficient and error prone. Moreover, the repetitive sending of test patterns and test results back and forth between various working groups of semiconductor artisans, e.g., across potential network or entity boundaries, presents multiple stages or opportunities from which design security and related intellectual property may be compromised.
Approaches described in this section may, but have not necessarily been conceived or pursued previously. Unless otherwise indicated, approaches mentioned (or issues identified in relation thereto) should not to be assumed as admitted or recognized in any alleged prior art merely by inclusion in this section.